I ve been AWOL for most of the debian project leader election campaigns this year, but I still want to vote, so I ve been dredging the emails on the last day. Maybe someone still has to vote and reads this, or maybe it ll help someone to interpret the result. What I ve done this year is to make a quick tally of platform points and campaign answers that I liked and disliked for each candidate, then total them up to get an order. If anyone gets a negative (more dislikes than likes), then I ll rank them below NOTA. Platforms: Margarita Manterola, Stefano Zacchiroli, Wouter Verhelst, Charles Plessy. Some of the questions:

• Do you plan on taking on a 2IC or a team? No SZ, WV, CP, MM
• What do you think are valid goals to spend donated money on? How would you think is a valid way to thank (hardware) contributors? What qualifies a Debian Partner ? Spend on what we cannot receive by donation CP. Partner is defined on website CP. Spend on maintenance, development, contributions, use MM. Spend on keeping the project running and emergency reserve SZ. Partnership programs usually require an yearly subscription fee SZ. No specific spending list WV. No formal list of partners WV
• How much time do you currently/would you devote to Debian? Couple of evenings per week and a couple of days per month CP. A daily hour, more in future MM. 1-2 hours/day + 2-4 hours/week SZ. Varies WV.
• infrastructure to finance Debian related projects? Why not use other infrastructure? CP, MM. Don t SZ, WV.
• Please finish In ten years I d like Debian . to still be thriving as the Universal OS MM. to be *THE* renowned distribution in terms of freeness and democracy SZ. to be mainstream CP. to still be the distribution I consider to be the best one out there WV
• Do you think current frequency/amount of heated discussions is acceptable for the Debian project? What would you do to reduce those? too agressive, use social pressure MM. Acceptable? No. Normal? To some extent, yes. DPL must set a good example SZ. Stricter policies CP. No amount of ad-hominem attacks is acceptable, see platform WV.
• Which project and external Debian-related communications media do you follow? and contribute to? lists, IRC, planet MM, WV. lists, Planet CP. lists, IRC, planet, DN, identi.ca SZ.
• How, as DPL, you would (or even could) address the social issues around releasing? add manpower MM. status reports SZ. public disappoval of bad behaviour WV. reshape the archive CP
• should we try to coordinate our release process with Ubuntu s? Yes MM, SZ. Why not WV. More info CP
• Will you withdraw delegations of DD not behaving correctly? On recurrence MM, CP. No(?) SZ. No WV.
• Is there any part of Debian that should be restricted to a small subset of developers? Yes WV, CP, MM. No except security reasons SZ.
• Personal mentoring? Good idea MM. Recycle NM process CP. Use teams SZ. NM already is mentoring WV.
• Standardization, large scale changes, innovations valuable questions, but the responses are too complex to summarise here, sorry.
• How would you enforce Debian Community Guidelines? wouldn t SZ, MM, WV. No clear answer from CP.
• is planet.d.o a good thing? Not necessarily WV. No clear answer from SZ, MM. No reply from CP.
• How do we face the challenge to do more every year? improve our way of working and get more people to help us do our jobs MM. open Debian s door wider CP. have enough people to work on Debian WV. use our communication media SZ

Make of that what you will. It surprised me which way the scores came out, but there was one answer with such a massive problem (in my opinion) that I ranked its giver equal with the next candidate down anyway. If you re a debian developer (DD), have you voted yet?

Serafeim Zanikolas:

With respect to attracting new contributors, please ponder the idea of a formal one-on-one mentoring scheme (as opposed to one-off interactions via d-mentors).

I see nothing particularly objectionable about this. A long time ago people were talking about replacing NM with a saner mentoring process, and I am certain that mentoring occurs unofficially. I see no reason that you could not set up a formal one-on-one mentoring infrastructure with or without the Project's blessing. Charles Plessy:

So my question to other candidates is simple: what is your opinion and program about membership?

I think that we have enough inequality in the project as it is. That is why I consider DM to be a bad thing, even though it has practical benefits. I think that NM is probably fundamentally broken, and I get a bit nervous when people are talking about increasing the amount of NM indoctrination or bureaucracy. I would be in favor of exploring the replacement of NM with some kind of mentorship-type process, though I would worry it would not scale. I would be in favor of exploring the replacement of NM with something like Lars's proposal a while back, though I would worry that it would encourage popularity contests and cliques and cabals. Raphael Hertzog:

1/ Do you believe that it's a good move to standardize our packaging tools? (example: debhelper is almost standard, quilt is gaining status of the standard patch system thanks to the new source format) 3/ Do you have any preference on the tools that we should try to standardize on (which source format/patch system, dh7/CDBS/yada/etc., VCS helper, etc.)? 4/ Organizing changes that have an impact on (a large part of all) the archive is very difficult: How can we change our processes so that doing/organizing such changes is less of a burden? 5/ I have the feeling that Debian is innovating less than it used to do. We are more often followers rather than leaders. Do you share that feeling? What shall we do to make that change?

1/ I think that we should standardize on dpkg-dev. If there are features which absolutely every package needs, it would seem the logical place to add them. 3/ Right now I wish everyone were using git, but I do not believe in forcing them. Of the available source formats, I like 3.0 (quilt) with no additional patch system, and no package helpers at all. I am not quite sure what a VCS helper is so I have no known preference to express. 4/ I am not sure whether or not what you are talking about should, in fact, be less of a burden, and why it should or should not, so I do not have a valid opinion on how to change the process. 5/ I do share that feeling. I think that sometimes we get bullied by Ubuntu when there are things we would do for our own benefit which would make their lives difficult. I think that people are generally resistant to change, even when it would be of little cost to them and great benefit to someone else. These problems are social and might be correctable with a better spirit of teamwork and cooperation. However, I do not think we should be innovating just for innovation's sake or to be known as the most innovative kid on the block. We should be making my favorite operating system.

Bernd Zeimetz:

From the other candidates I'd like to know their opinion and plans (if there are any) about license/copyright requirements in Debian.

I believe that intellectual property laws are wrong and should be abolished, so I am not particularly in favor of giving copyrights any more respect than necessary. However, I do not think that Debian is the place to undermine copyright, and that we should attempt to maintain standards which not only protect people from legal liability, but are also in the best interests of our developers and users. I do not know what level of nitpicking best serves our developers and users. A GR seems like an interesting way of determining at part of that. Anthony Towns:

What's your estimate of the current number of Debian users?

I do not have one. While I do acknowledge that the number of users does affect us in terms of potential contributor base, and scaling issues (including bug reporting), I do not think that the exact number is important at all to what we do. Also I would hope that whichever DPL is elected chooses to focus on practical matters rather than academic exercises. Kurt Roeckx:

I think that one of issues we have is that there is alot of work to be done by some teams, some of them even regularaly mail that they need more members, but they seem to have a hard time keeping the numbers up, burning the other team members out. What are your ideas to make sure those teams keep running?

• Diffusion of power throughout the rest of the project
• Delegation of people who do not seek to be core team members if they have the time, are willing, and would make good additions.

Note that I do not think it appropriate either for core teams to choose their own members or to reserve the privilege of demanding that a new person be able to work with them in a certain way. An ideal team member should be able to work with anyone. If the existing delegates are unable to work with new people, perhaps they are not ideal team members. Charles Plessy:

During the discussions that started after the GR, I suggested that the GR proposer should have more control about the options put to the vote. In particular, it would be useful if he can refuse an option that would disequilibrate the voting system. That would make him responsible for the success of the GR: discarding a popular option is taking the risk that the whole GR is refused and the option is accepted as a separate GR, which is the kind of public failure that I expect that people will avoid.

I do not think GR proposers should have any special control over general resolutions beyond what is Constitutionally granted at present. In fact, I would prefer if people did not try to propose multiple options or strategically craft ballots for any purpose. To me, the only honest method is to propose the outcome one genuinely wants to win, and let our strange and special brand of parliamentary procedure take care of the rest. As for the supermajority issue, I am not a huge fan of political word games. Debian distributes non-free software. We have a non-free section within our normal infrastructure, and while it is segregated and does not receive quite the same love that main does, it is still very much part of what we work on and distribute from our official infrastructure. So there is no amount of word lawyering, cognitive dissonance, or NM indoctrination that can make me believe that it is an honest statement to say that non-free is not part of Debian. Likewise I do not believe in redefining success or the meanings of Foundation Documents. I do not think that we should allow ourselves to pass any kind of magical resolution that contravenes the DFSG or Social Contract without actually modifying them. That seems utterly absurd to me, and I have seen what has become of the United States government.

The nomination period for the Debian Project Leader Elections 2010 is over and we have 4 candidates this year:

1. Stefano Zacchiroli [nomination mail]
2. Wouter Verhelst [nomination mail]
3. Charles Plessy [nomination mail]
4. Margarita Manterola [nomination mail]

For the next 3 weeks, you can ask your questions and follow the debate in the debian-vote mailing list.

Copy of http://lists.debian.org/debian-devel/2009/04/msg00421.html. Hi folks, We have been pretty busy these past few weeks with the whole Google Summer of Code 2009 student application process.
I can say that we have this year a very good set of proposals and I d like to thank all the students and mentors for this. I am going to present to you our shortlist of projects that we would like to be funded and believe we can reasonably manage to get funded. As always, remember that the number of slots is not final yet at this point so we can t promise anything. The first preliminary slot count given today was *10* (same as last year) and we hope to get *2* more (as we did last year). This shortlist is alphabetically ordered because we don t want to reveal the current internal rankings. I am inviting you to debate what you think is cool, what is useful, what is important to Debian, maybe give us pointers to resources or people that could be helpful for the projects. We will try to alter our current rankings to reflect the zeitgeist in Debian, while taking into account the personal information that we have about each student involved. The deadline for any modification is on the 15th, so get everything in by the 14th. The final selected projects will be announced by Google April 20th, ~12 noon PDT / 19:00 UTC. We ll have another announcement then. Three proposals need or may need a mentor, I indicated it. For more information about the projects or mentoring and how to talk to us directly, scroll down past the list. Debian s Shortlist : - Aptitude Package Management History Tracking
- Automatic Debug Packages Creation and Handling
- Debbugs Web UI: Amancay Strikes Back
- Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings
- Debian-Installer Support for GNU/kFreeBSD
- KDE/Qt4 Adept 3.0 Package Manager
- Large Scientific Dataset Package Management
- MIPS N32 ABI Port
- MTD Embedded Onboard flash Partitioning and Installation
- On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration
- Port back update-manager to Debian and all Derivatives
- Debian Autobuilding Infrastructure Rewrite And the details: Aptitude Package Management History Tracking Student: Cristian Mauricio Porras Duarte, Mentor: Daniel Burrows Aptitude currently does not track actions that the user has performed beyond a single session of the program. One of the most frequent requests from users is to find out when they made a change to a package, or why a package was changed; we want to store this information and expose it in the UI in convenient locations. As a side effect, this might also provide some ability to revert past changes. Automatic Debug Packages Creation and Handling Student: Emilio Pozuelo Monfort, Mentor: Marc Brockschmidt This proposal aims at providing debug binary packages for the packages in the Debian archive in an automatic manner, moving them away from the official Debian archive to an special one. This has the benefits of providing thousands of debug packages without any work needed from the developers, for all the architectures, without bloating
the archive. Debbugs Web UI: Amancay Strikes Back Student: Diego Escalante Urrelo, Mentor: Margarita Manterola The Amancay project aims to be a new read/write web frontend to Debian s BTS; allowing DDs and contributors to easily interact with bugs via an intuitive yet powerful interface, enabling new workflows and creating new contribution opportunities like triaging while upholding reporting quality. Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings Student: Jonathan Yu, Mentor: (probably) Dominique Dumont see below This project proposes a common library for parsing and manipulating Debian Control files, including control, copyright and changelog. Main ideas include validating and parsing of these files, with both Strict and Quirks modes for the parser. The second idea is a new frontend for Debconf using Qt4 (for which Perl bindings will be written). Debian-Installer Support for GNU/kFreeBSD Student: Luca Favatella, Mentor: Aurelien Jarno GNU/kFreeBSD is currently using a hacked version of the FreeBSD installer combined with crosshurd as its own installer. While this works more or less correctly for standard installations (read: the exact same installation as in the documentation), it does not allow any changes in the installation process except the hard disk partitioning. This project is about porting debian-installer on GNU/kFreeBSD, and to a bigger extent, make debian-installer less Linux dependant. KDE/Qt4 Adept 3.0 Package Manager Student: Mateusz Marek, Mentor: NEEDS MENTOR, see below. Finish Adept 3.0, a fully integrated package manager for Qt4/KDE4. Adept is currently the only viable path to a Debian native package manager on KDE that would support modern features such as tags, indexed search or good conflict resolving. With Aptitude-gtk still in development and only available for GTK+ and (K)PackageKit having fundamental problems, Debian needs this project to stay in control of its package management on KDE after much neglect in the recent years. Large Scientific Dataset Package Management Student: Roy Flemming Hvaara, Mentor: Charles Plessy Large public datasets, like databases for bioinformatics are typically too big and too volatile to fit the traditional source/binary packaging scheme of Debian. There are some programs that are distributed in Debian, like blast and emboss, that can index specialised databases, but Debian lacks a tool to install or update the datasets they need and keep their indexing in sync. MIPS N32 ABI Port Student: Sha Liu, Mentor: Anthony Fok This project first focuses on creating a new MIPS N32 ABI port for Debian. Different from O32 and N64, N32 is an address model which has most 64-bit capabilities but using 32-bit data structures to save space and process time. A second focus will be given on making such a mipsn32el arch fully optimized for the Loongson 2F CPU which gains more and more popularity in subnotebooks/netbooks in many countries. MTD Embedded Onboard flash Partitioning and Installation Student: Per Andersson, Mentor: Wookey Many embedded devices have MTD onboard flash as persistent storage like the Kurobox Pro NAS, the Neo Freerunner, the Sheeva Plug or the OLPC. With MTD flash being so popular and with increases in capacity, support for MTD partition/installation would make Debian even more interesting to a wide range of of devices, making it one step closer to being universal. On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration Student: David Wendt Jr, Mentor: (probably) Steffen Moeller see below In many academic fields, as well as commercial industries, people use clusters to distribute tasks among multiple machines. Many times this is done by packaging a whole operating system disk image, uploading it onto the cluster, and having the cluster run it in a VM. This project intends to make it easier for Debian to distribute prepared disk images templates like they distribute CD images now, for the users to recreate or customise these templates with Debian packages and for administrators to host such clusters with Debian. Port back update-manager to Debian and all Derivatives Student: Stephan Peijnik, Mentor: Michael Vogt The project would involve taking the distribution-(Ubuntu-)specific update-manager code, analyzing it, and creating a package with just its core functionality, decoupling the distribution-specific parts and thus making the core code extensible by distribution-specific add-ons. This in turn would remove the need of porting update-manager to Debian with every upstream release. An additional optional goal would be replacing the synaptics-backend with a python-apt based one. Debian Autobuilding Infrastructure Rewrite Student: Philipp Kern, Mentor: Luk Claes Rewrite the software that currently runs the Debian autobuilding infrastructure in a way that makes it more maintainable and robust. It will use Python as its programming language and PostgreSQL for the database backend. By harmonizing buildds, many build failures can be prevented and wasteful workload on buildd volunteers can be reduced. On mentoring:

• KDE/Qt4 Adept 3.0 Package Manager:

Petr Rockai, the original developer of Adept has offered help to anyone willing to adopt Adept. Sune Vuorela has offered help for any Qt4 and KDE related issues. *We really need a mentor here*. The student is quite competent but Google dictates that we provide a mentor to handle student management.

• Control Files Parsing/Editing Library/Qt4-Debconf Qt4-Perl bindings:

Dominique Dumont, although not DD, has signaled interest in mentoring this, although it hasn t been confirmed yet. Sune Vuorela has offered to help co-mentor for the Qt4-Debconf and Qt4-Perl bindings part.

• On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration:

Steffen Moeller has signaled interest in mentoring this, although it hasn t been formally confirmed yet. Charles Plessy of the Debian Med team will provide help for use cases related issues. Eric Hammond, developer of the original vmbuilder image creation tool and maintainer of a set of Debian and Ubuntu images will provide help for Amazon EC2 and image creation issues. Chris Grzegorczyk from the Eucalyptus team will provide help for Eucalyptus and Eucalyptus/Debian integration issues. Contacting us: Considering the tight schedule, most stuff happens live on IRC: #debian-soc on irc.debian.org You can also consult our wiki page for some additional information:
<http://wiki.debian.org/SummerOfCode2009> We have a mailing-list at:
<http://lists.alioth.debian.org/mailman/listinfo/soc-coordination> Keep this discussion on debian-devel@lists.debian.org while cc-ing soc-coordination@lists.alioth.debian.org. This thread is for debian-devel primarily.

A quick update before the big one about the 2009 Google Summer of Code. I believe we had a great recruitment drive this year and we have a very good set of proposals to work with. We d like to thank everyone involved for their help. We re now ranking out student applications. I promised elsewhere that I ll send out our shortlist of projects once Google sends us our preliminary slot allocation today but I misread the thread on the -mentors list and that count will only happen on Thursday, so we ll have to wait a bit more. That shortlist would only include projects, but not individual students. The idea is to give a heads up to everyone before committing to a group of projects and students. It is very important to inform the community as it increases visibility of the students work, giving them more help and support (and also avoids duplicating existing not yet publicized work!). As far as mentors go, we should have all of our approximately 14 planned projects covered, except for 2. I m posting them here in case you could mentor or help find mentors for those projects. (The wiki pages are not really up to date, so please come on IRC and ask clarifications, see below)

• Qt4 Package Manager:

Finish Petr Rockai s Adept 3.0 and bring a Qt4 Package Manager to Debian, with a different interface paradigm than Aptitude-gtk.
Petr said he would provide help with the existing codebase but can t mentor. Sune Vuorela from Debian KDE is ready to help with Qt4 related issues.

• EC2/Eucalyptus:

Build Debian tools to create Debian images for Amazon EC2 and the free Eucalyptus implementation. Packaging of the Eucalyptus hosting framework is also possible.
For this project, we already have on board to help: Charles Plessy from Debian Med, Eric Hammond, developer of the existing vmbuilder Ubuntu tool for EC2 and Chris Grzegorczyk and Rich Wolski, from the Eucalyptus team. Plenty of people to get help from. Mentoring is a great experience! See this for what it entails. If we still can t find a mentor by the end of the week, I ll blast an announcement over at debian-devel@l.d.o along with the project shortlist. In the meantime, don t forget to idle on #debian-soc on irc.debian.org.

Another point release for Etch has been done; now it's the time for the CD team to roll out new images after the next mirror pulse. The official announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow shortly afterwards. FTP master of the day was Joerg Jaspert, who did his first point release since Woody, as he told us on IRC. We appreciate your work and you spending your time that shortly before going to Argentina. This point release includes the etchnhalf update introducing a new kernel image (based on 2.6.24) and some driver updates. Additionally the infamous openssl hole will be fixed for good, even for new installs. Again I want to present you a list of people who contributed to this release. It cannot be complete as I got the information out of the Changed-by fields of the uploads.

• akira yamada
• Alexander Sack
• Alexander Schmehl
• A Mennucc1
• Andrea De Iacovo
• Andres Salomon
• Aurelien Jarno
• Charles Plessy
• Christian Perrier
• Christian Welzel
• Colin Watson
• dann frazier (indefatigable kernel worker, most sourceful uploads)
• Darren Salt
• Devin Carraway (3rd place of sourceful uploads, due to security work)
• Emmanuel Lacour
• Eric Dorland
• Fabio Tranchitella
• Faidon Liambotis
• Fathi Boudra
• Florian Weimer
• Francesco Paolo Lovergine
• Francois Marier
• Frank Lichtenheld
• Frans Pop (thanks for your d-i work!)
• Frederic Peters
• Gregory Colpart
• Holger Levsen
• Jan Wagner
• Jay Berkenbilt
• J r my Bobbio
• Joey Hess
• Joey Schulze
• Josselin Mouette
• Julien Cristau
• Kai Hendry
• Kurt Roeckx
• LaMont Jones
• Laszlo Boszormenyi
• Martin Pitt
• maximilian attems
• Michael Biebl
• Michael Koch
• Mike Hommey
• Moritz Muehlenhoff
• Noah Meyerhans
• Ola Lundqvist
• Otavio Salvador
• Patrick Matth i
• Petter Reinholdtsen
• Philipp Kern
• Pierre Habouzit
• Raphael Hertzog
• Rene Engelhard
• Robert Millan
• Roberto Lumbreras
• Roland Mas
• Romain Beauxis
• Russ Allbery
• Sean Finney
• Stefan Fritsch
• Steffen Joeris
• Stephen Gran
• Steve Kemp
• Sune Vuorela
• Thijs Kinkhorst (2nd place of sourceful uploads, due to security work)
• Thomas Viehmann
• Toni Mueller
• Tzafrir Cohen

From the Release Team we had dann frazier (who drove the important kernel part of etchnhalf), Luk Claes, Neil McGovern, Andreas Barth, Martin Zobel-Helas and me working on it. ;-)

Yesterday we had another Tokyo Debian meeting. It is a monthly meeting held in Tokyo, Japan.approx. 23 people attended.Kobayashi, kashiwagi, kurasawa, Maeda, Sutou, Muto, Yamane, Nokubi, Komuro, Takasugi, Eto, Yoshida@Itabashi, mhatta, Kitahara, gotom, nakano, ysjj. Matsuyama, Kawachi, David Smith, Charles Plessy, et moi.Report follows:

Apparently a week’s mail is a 166MB these days for me; I may be on too many lists. In the past week, 1.9kB of that mail were a couple of missives from Charles Plessy, related to one of my blog posts from last month. Apparently he’s embarassed at being associated with what he wrote, and seems to think the best way to approach this is to assert absolute control over the text as his intellectual property and threaten to contact my ISP. Obviously, I disagree, both morally on the grounds that I don’t care for supposed supporters of free software that resort to insults and legal threats, and legally on the grounds I don’t think Charles has any reasonable case to disassociate himself from his own words. Just for the hell of it, his followup mails and mine are below the fold. Read the rest ...

So following Florian’s chastisement of my “threatening” fellow Debian developers, Charles Plessy becomes annoyed by a bug in apt-file (its default configuration expects curl, but wget is what’s installed on most systems), at which point Luk Claes then starts threatening to NMU whether the maintainer likes it or not. Naturally that’s not the correct thing to do for a report the maintainer’s addressed and said is not a bug, 0-day NMU policy or not. Naturally, pointing this out brings Charles back into the fray, to complain further. A followup to that produces this off-list reply from Charles:

On Fri, Jan 13, 2006 at 05:13:15PM +1000, Anthony Towns wrote :
> I'm not disputing whether it's a bug or not, the maintainer is. If
> you are *helping* the maintainer, then fine: do an NMU.
Dear Anthony,
I would love to, but I am not a developer. And I am amazed to see that
more energy is spent in arguing rather than solving the problem. I hope
Luke will NMU this package and close those shameful bugs.
> In my experience you almost always get a better response from people if
> you assume they've got a good reason for doing what they have been doing,
> rather than just trying to add extra punctuation to your sentences.
> Admittedly, punctuation is pretty cool...
That kind of sentence reflects your inclination for ad-hominem attacks.
They poison the -devel list.
Best,

So yay for people who aren’t developers, in the n-m queue or maintaining a package, who don’t understand Debian’s processes, yet still think it’s great to pontificate about what Debian’s processes are, go on about how developers are “arrogant experts” and who think “punctuation is pretty cool” is a “poisonous ad hominem attack”. But what I hate most is people who think they’re contributing to Debian by mailing people privately to tell them how horrible they are. Gag. For those playing along at home, the proper process to follow in a dispute with a maintainer is to bring it up to the technical committee, not to try forcing the situation, whether that be by reopening bugs or playing bug ping-pong. It’s really not complicated. It’s even documented (5.8.3 of the Developers Reference).

So following Florian’s chastisement of my “threatening” fellow Debian developers, Charles Plessy becomes annoyed by a bug in apt-file (its default configuration expects curl, but wget is what’s installed on most systems), at which point Luk Claes then starts threatening to NMU whether the maintainer likes it or not. Naturally that’s not the correct thing to do for a report the maintainer’s addressed and said is not a bug, 0-day NMU policy or not. Naturally, pointing this out brings Charles back into the fray, to complain further. A followup to that produces this off-list reply from Charles:

On Fri, Jan 13, 2006 at 05:13:15PM +1000, Anthony Towns wrote :
> I'm not disputing whether it's a bug or not, the maintainer is. If
> you are *helping* the maintainer, then fine: do an NMU.
Dear Anthony,
I would love to, but I am not a developer. And I am amazed to see that
more energy is spent in arguing rather than solving the problem. I hope
Luke will NMU this package and close those shameful bugs.
> In my experience you almost always get a better response from people if
> you assume they've got a good reason for doing what they have been doing,
> rather than just trying to add extra punctuation to your sentences.
> Admittedly, punctuation is pretty cool...
That kind of sentence reflects your inclination for ad-hominem attacks.
They poison the -devel list.
Best,

So yay for people who aren’t developers, in the n-m queue or maintaining a package, who don’t understand Debian’s processes, yet still think it’s great to pontificate about what Debian’s processes are, go on about how developers are “arrogant experts” and who think “punctuation is pretty cool” is a “poisonous ad hominem attack”. But what I hate most is people who think they’re contributing to Debian by mailing people privately to tell them how horrible they are. Gag. For those playing along at home, the proper process to follow in a dispute with a maintainer is to bring it up to the technical committee, not to try forcing the situation, whether that be by reopening bugs or playing bug ping-pong. It’s really not complicated. It’s even documented (5.8.3 of the Developers Reference).